MKE host network namespace must not be shared.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-260913	CNTR-MK-000150	SV-260913r966096_rule		Medium

Description
MKE can be built with privileges that are not approved within the organization. To limit the attack surface of MKE, it is essential that privileges meet organization requirements. The networking mode on a container when set to --net=host, skips placing the container inside a separate network stack. This is potentially dangerous because it allows the container process to open low-numbered ports like any other root process. Thus, a container process can potentially do unexpected things such as shutting down the Docker host. Do not use this option. By default, bridge mode is used.

Description

MKE can be built with privileges that are not approved within the organization. To limit the attack surface of MKE, it is essential that privileges meet organization requirements. The networking mode on a container when set to --net=host, skips placing the container inside a separate network stack. This is potentially dangerous because it allows the container process to open low-numbered ports like any other root process. Thus, a container process can potentially do unexpected things such as shutting down the Docker host. Do not use this option. By default, bridge mode is used.

STIG	Date
Mirantis Kubernetes Engine Security Technical Implementation Guide	2024-06-17

Details

Check Text ( C-64642r966094_chk )
When using Kubernetes orchestration, ensure that Pods do not use the host machine's network namespace and uses its own isolated network namespace. Note: If the hostNetwork field is not explicitly set in the Pod's specification, it will use the default behavior, which is equivalent to hostNetwork: false. Execute the following for all pods: kubectl get pods --all-namespaces -o json \| jq '.items[] \| select(.spec.hostNetwork == true) \| .metadata.name' If the above command returns a namespace then the "hostNetwork" = true, this is a finding unless a documented exception is present in the System Security Plan (SSP). When using Swarm orchestration, check that the host's network namespace is not shared. Via CLI: Linux: As an administrator, execute the following command using a Universal Control Plane (MKE) client bundle: docker ps --filter "label=com.docker.ucp.version" \| awk '{print $1}' \| xargs docker inspect --format '{{ .Name }}: NetworkMode={{ .HostConfig.NetworkMode }}' If the above command returns NetworkMode=host, this is a finding unless a documented exception is present in the SSP.

Check Text ( C-64642r966094_chk )

When using Kubernetes orchestration, ensure that Pods do not use the host machine's network namespace and uses its own isolated network namespace.

Note: If the hostNetwork field is not explicitly set in the Pod's specification, it will use the default behavior, which is equivalent to hostNetwork: false.

Execute the following for all pods:

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.hostNetwork == true) | .metadata.name'

If the above command returns a namespace then the "hostNetwork" = true, this is a finding unless a documented exception is present in the System Security Plan (SSP).

When using Swarm orchestration, check that the host's network namespace is not shared.

Via CLI:
Linux: As an administrator, execute the following command using a Universal Control Plane (MKE) client bundle:

docker ps --filter "label=com.docker.ucp.version" | awk '{print $1}' | xargs docker inspect --format '{{ .Name }}: NetworkMode={{ .HostConfig.NetworkMode }}'

If the above command returns NetworkMode=host, this is a finding unless a documented exception is present in the SSP.

Fix Text (F-64550r966095_fix)
When using Kubernetes orchestration: In Kubernetes, the hostNetwork setting is a part of the Pod's specification, and once a Pod is created, its hostNetwork setting cannot be directly modified. However, the desired effect can be achieved by creating a new Pod with the updated hostNetwork setting and then deleting the existing Pod. This process replaces the old Pod with the new one. When using Swarm orchestration: Review and remove nonsystem containers previously created by these users that allowed access to the host network namespace must be removed using: docker container rm [container]

Fix Text (F-64550r966095_fix)

When using Kubernetes orchestration:
In Kubernetes, the hostNetwork setting is a part of the Pod's specification, and once a Pod is created, its hostNetwork setting cannot be directly modified. However, the desired effect can be achieved by creating a new Pod with the updated hostNetwork setting and then deleting the existing Pod. This process replaces the old Pod with the new one.

When using Swarm orchestration:
Review and remove nonsystem containers previously created by these users that allowed access to the host network namespace must be removed using:

docker container rm [container]